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REMARKS 

Reconsideration and further examination is respectfully requested. Claims 1, 3-6 and 8 
are currently pending in this application. 

Rejections under 35 U.S.C. 6102(el 

Claims 4 and 5 were rejected under 35 U.S.C- §102(e) as being anticipated by Borella et 
al, U.S. 6.643,259* 
Borella: 

Borella describes the use of a combination of typical TCP behavior in conjunction with a 
maximum congestion window for the purposes of controlling data transfer across an interface at 

column 13, lines 3-62: 

"...A maximum congestion window ("cwnd*") is computed al Step 186. The 
maximum congestion window cwnd* is to be distinguished from the sliding congestion 
window cwnd described above. The value of the maximum congestion window is 
computed in response to the product b.time$.RTT, where b is the value of the constant 
bitrate..., b-times*RTT is the number of bits that can be unACKed at any one time 
between the first network device 14 and the second network device 16. Thus, TCP 62 is 
able to determine, from a given bitrate b and its running value of RTT, what its cwnd* 
value should be.... 

A congestion window value is obtained from a congestion control process in the 
lower layer of the protocol stack for the first network device 14 at Step 188. In one 
exemplary preferred embodiment, the congestion window value is cwnd as obtained 
from the TCP 62 process 120 of FIG. 4 and depicted in FIG. d- ... 

At Step 190, the transfer of an amount of data is made from the higher layer to the 
lower layer of the protocol stack for the first network device equal to a minimum of the 
congestion window value and the maximum congestion window. ...Ordinarily, TCP 62 
increases cwnd until there is a timeout when data packets are unACKed or there are 
duplicate ACKs. This behavior produces the characteristic n sawtooth wave" effect of FIG. 
6. However, if the amount of data transferred is never increased beyond cwnd*, a 
timeout will not happen and the first network device's 14 data throughput is more 
likely to remain constant, near the given bitrate b.... In another exemplary preferred 
embodiment, the TCP 62 process limits itself so that cwnd is never increased beyond 
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cwnd* Step 190 of Method 1 80 includes determining whether cwnd is greater cwnd*, 
and if so, replacing the cwnd with the cwnd* in the TCP 62 process. Hie amount of data 
transferred from the application layer to the transport layer of the protocol stack 50 is 
equal to cwnd*. A TCP 62 process that limits itself so that cwnd is never increased 
beyond cwnd* may not provoke a timeout and the first network device's 14 TCP 62 
throughput is more likely to remain constant. In these embodiments, all other aspects of 
TCP 62 are essentially unchanged. For example, if a packet is unACKed, cwnd is reduced 
to MSS as before. This will guarantee that a TCP 62 layer including the above-described 
Method 180 will still exhibit TCP's 62 characteristics when not using a CBR channel to 
itself.,,. 

Accordingly, it would appear that Borella seeks to control the transfer of data over 
an interface so that congestion does not occur. Applicant's position is strengthened by 
the example cited by Borella which recites: 



"... FIG. 8 is a diagram illustrating the throughput of an optimized congestion 
control process for a constant bitrate channel as described above. After a timeout 200, the 
congestion window and throughput increase according to an existing TCP 62 process. 
Above ssthresh, the value of cwnd will increase linearly 202 until it reaches the value of 
the maximum congestion window cwnd* 204. The value of cwnd* 204 is computed in 
response to the product of the continually updated return trip time RTT and the constant 
bitrate b for the CBR channel. The throughput is prevented from overextending 
beyond the capacity 168 of the channel and periodically suffering timeouts,... For the 
constant bitrate channel described herein, the throughput stops short of overextending 
itself and morefidly and efficiently uses the capacity of the channel The throughput may 
remain at the optimal level for extended periods of time but may face an occasional 
timeout 206 from fluctuations in the round trip delay time. As can be seen from FIG. 8, 
TCP 62 uses close to all of the available capacity of a CBR channel. In addition, the 
Method 810 for optimizing data transfer is essentially independent of the version of TCP 
62 that is running in the transport layer..." (Borella, column 14, lines 14-37) 



Borella thus seeks to provide a system in which 'timeouts do not occur % where the 
timeout is *the detection of a congestion condition* that previously caused the congestion 
window to be halved, thereby reducing the available bandwidth transfer on the link. To overcome 
this situation, Borella proposes a scheme whereby the data that is forwarded on the link is 
incrementally increased until a maximum congestion window is met. Data is prevented from 
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being transferred from an upper level protocol of an application to a lower level protocol at any 

rate that exceeds the maximum congestion window. 

In contrast, claim 4 as amended now recites "... A method of controlling congestion in a 
communications network, the method comprising ... detecting a congestion condition in a 
connection between two nodes in the communications network, the connection having a desired 
bandwidth,... and upon detection of the potential congestion condition, controlling new traffic 
emitted into the network to be no more than a current unacknowledged traffic load of the 
network at the time of detection..." 

Applicants can find no such teaching ui Borella. Rather than allow traffic to be placed on 
a network until a congestion condition is detected, Borella limits the output of traffic onto a 
network, to prevent congestion from occurring. In contrast, the present invention permits traffic 
to be forwarded onto a network until congestion occurs, at which point the traffic is reduced in a 
controlled manner. Accordingly, for at least the reason that Borella fails to describe or suggest 
every limitation in the claims, the rejection of claim 4 under 35 U.S.c. §l02(e) is improper, and 
should be withdrawn- 



Applicants claim 5, as amended, now recites "...The method of claim 4, wherein the 
network is a private network, and wherein a total bandwidth of the private network is allocated 
among a plurality of connections between a plurality of nodes in the private netwoik to provide a 
desired bandwidth for each connection, and wherein the step of controlling new traffic maintains 
the desired bandwidth on the connection..." No such structure is found in Borella. 

The Examiner stares, at page 2 of the office action "Borella describes that the data 
network can be a campus network or a private network..." However, Borella neither describes 
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nor suggests that 'a total bandwidth of the private network is allocated among a plurality of 

connections." Accordingly for at least the reason that Borella fails to describe all the limitations 

of claim 5 it is respectfully requested that the rejection has been overcome and should be 

withdrawn. 

Rejections under 35 U.S.C. $103 

Claims 1, 3 6 and 8 were rejected under 35 U.S.C. §103(a) as being unpatentable over 
Borella in view of Ohyama et al. (U.S. 6,278,691). 



Ohvama: 

Ohyama describes, in the Abstract "...A communications system has a real time signal 
generating part for generating the real time signal of data rate R with one frame as one unit; a 
transmission part, having a transmission rate C (C>R), over which the real time signal is 
transmitted; and a real time signal outputting part for outputting the real time signal stored in a 
real time signal receive buffer part, wherein after storing the real time signal for a prescribed 
number, N, of frames in the real time signal receive buffer part, the real time signal outputting 
part is activated, thereby performing control so that all generated portions of the real time signal 
can be output at the receiving end without interruption..." 

Ohyama is concerned with the impact of network congestion on real-time signaling. The 

Examiner relies on Ohyama*s teaching of the concepts of TCP* in particular the paragraph 

spanning column 5 lines 66 through column 6 lines 9, which states: 

" ... To avoid congestion collapse, in TCP it is recommended to use two techniques, slow 
start and multiplicative decrease congestion avoidance.... In multiplicative decrease congestion 
avoidance, a second restriction called a congestion window is provided to control congestion, and 
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anytime, TCP compares the receiver's window size (buffer size) with the congestion window size 
and uses the smaller window in transmission. Each time a segment loss is detected, the 
congestion window size is reduced by one half (the minimum value is 1 segment) and the 
timeout interval is doubled. This strategy provides a quick and significant decrease in traffic and 
allows a sufficient time to clear the datagrams already queued at the router... When it is 
determined that the congestion has ended, TCP initializes the congestion window to 1 , sends the 
first segment, and waits for an acknowledgement. Thereafter, the congestion window is increased 
by one segment each time an acknowledgement arrives. This technique is called slow start.... 
To prevent the window size from increasing too rapidly and thereby causing congestion again, 
TCP provides a still another restriction. That is, when the congestion window size reaches one 
half of its original size, TCP enters a congestion avoidance stage and reduces the increasing 
speed of the congestion window size. During the congestion avoidance period, the congestion 
window is increased only by 1 even if the acknowledgements for all the segments in the window 
are received... The above has described the process in TCP from the occurrence of congestion to 
the recovery from the congestion. While this process is in progress, the network can only 
transmit data at a lower transmission rate than its actual transmission capacity and imposes 
extra toads on end points. This presents a problem^ especially when transmitting real time 
signals- That is, the real time signals cannot be delivered in time and the real time requirement is 
impaired..." 

Thus Ohyama recognized much the same problem with TCP as Borella described with 

regard to Figures 5 and 6. hi contrast to Borella's solution (where transmissions are tightly 

controlled so that a limit is not exceeded) Ohyama accumulates data in advance. As stated at 

column 12, lines 6-15 of Ohyama: 

"„,The important point of the present invention is that even when the transmission 
capacity is temporarily restricted due to congestion, etc. rendering it impossible to transmit a real 
time signal within the real time, since data are accumulated in advance at the receiving terminal 
the real time signal can be output without interruption as long as the accumulated data are output, 
and when recovered from the congestion, the valid data accumulated in the transmit buffer are 
transmitted successively until data for a prescribed number of frames are accumulated in the 
receive buffer as in the previous normal operating condition...." 



The Examiner states, at pages 3-4 of the Office Action: 

Regarding claim 1, Borella discloses a method of controlling congestion between a first 
sender (figure 1, unit 14 and a second sender (figure 1, unit 16) in a communication 
network (see figure 1) comprising: entering a congestion avoidance state when some form 
of congestion has been detected (claimed detecting a potential network congestion 
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condition); wherein during the congestion avoidance state, a congestion window (cwnd) 
is increased so that the first device 14 transmits traffic in accordance with the available 
bandwidth of the network (claimed desired fixed bandwidth), see column 9, lines 64^67 

and column 10, lines 1-13 

Borella does not disclose connection bandwidth is lesser of a current amount of 
unacknowledged traffic emitted by the sender into a network at the time of detection of 
the congestion condition and a current receiver buffer size at that time.... However, 
Ohyama discloses providing a congestion window (Examiner interpreted the congestion 
window ay the bandwidth of the connection) for controlling congestion, and the receiver 
buffer size is compared with the congestion window size and uses the smaller window in 
transition (Connection bandwidth is lesser of a current amount of unacknowledged traffic 
emitted by the sender into the network at the time of the detection of the congestion 
condition and a current receiver buffer size at that time) See column 5,lines 66-67 and 
column 6 lines 1-11... 

Therefore it would have been obvious to an ordinary person of skill in the art at 
the time the invention was made to prevent the overflowing of Borella's receiver buffer 
using the congestion window method taught by Ohyama so that in addition to receiving 
new traffic at a congested phase of Borella, measures would be taken to not overflow the 
receiver buffer. The benefit would be better bandwidth utilization due to less congestion 
due to the receiver's buffer congestion eliminations../' 

Applicants respectfully disagree for the following reasons. 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. Finally, 
the prior art reference (or references when combined) must teach or suggest all the claim 
limitations. Applicants respectfully submit that the combination of Borella and Ohyama fails to 
satisfy these criteria with regards to claims 1, 3, 6 and 8 for the following reasons. 



h No motivation can be found for the modification suggested by the Examiner 

As discussed above, Borella determined that the current TCP architecture effectively cuts 
the transmission bandwidth in half when congestion is encountered (see Figures 5 and 6 of 
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Borella). Thus, Borella overcomes this problem by providing a maximum window, cwnd*, 
which is defined to be bxRTT, where b is the value of the desired constant bit rate, and RTT 
is a round trip transit time. Borella states "... the amount of data transferred is never 
increased beyond cwnd*" and with such an arrangement "a timout will not happen,-" In 
contrast Ohyama overcomes the same problem by adding additional buffering to ensure that 
real-time output can be maintained. 

The Examiner's motivation for combining the two references is "...Therefore it would 
have been obvious to an ordinary person of skill in the art at the time the invention was made 
to prevent the overflowing of Borella's receiver buffer using the congestion window method 
taught by Ohyama so that in addition to receiving new traffic at a congested phase of Borella, 
measures would be taken to not overflow the receiver buffer../' 

Applicant's disagree that such a motivation can be found in the combination of 
references, for at least the reason that Borella already describes a system where the buffer 
does not overflow because the data put into the pipe between the source and destination is 
limited to b x RTT. Accordingly for at least the reason that the motivation cited by the 
Examiner cannot be found in the combination of references, the rejection under 35 U.S.C. 
§103 is improper and should be withdrawn. 

2. There is no reasonable expectation of success from the combination suggested bv the 
Examiner 

Applicants note that Borella and Ohyama both seek to solve different problems. 
Borella seeks to deal with the problems caused by the current TCP congestion control 
protocol by limiting data that is put into the pipe to minimize the chance that congestion 
will occur. Ohyama seeks to ensure that real time data can still be output in the face of 
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congestion. Incorporating Borella's solution of limiting traffic that is put into the pipe 
would only serve to frustrate Ohyama's goal of providing real time data by reducing the 
overall bandwidth of the interface. 

With regard to Ohyama's description of the TCP congestion control mechanism, 
Applicants note that it is the same control mechanism that is described as problematic in 
Borella, namely 'Each time a segment loss is detected, the congestion window size is 
reduced by on&-half.. " As described in Borella with regard to Figure 5, cutting the 
transmission rate in half upon the detection of congestion serves results in 
underutilization of a data path, which is disadvantageous in a constant bit rate 
environment. 

Accordingly, for at least the reason thai the modification of the references 
resulting from the combination would serve to frustrate the goals of both Borella and 
Ohyama, there is no reasonable expectation of success resulting from the combination. 
For this additional reason, the rejection is improper and should be withdrawn. 



Combination neither describes nor suggests claimed invention 
Claim 1: 

However, even assuming that a proper combination of the references could be made, the 
combination still would neither describe nor suggest the limitations of the claimed invention as 
reflected in Claim 1, which recites "...A method of controlling congestion in a communications 
network, the method comprising .... detecting a network congestion condition on a connection 
between a sender and a receiver in the communications network, the network congestion 
condition detected in response to an occupancy threshold of a transmit buffer of the sender*, the 
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connection having a desired fixed bandwidth and upon detection of the potential network 
congestion condition, controlling new traffic emitted into the network to not exceed the desired 
fixed bandwidth for the connection, wherein the desired fixed bandwidth is the lesser of a current 
amount of unacknowledged traffic emitted by the sender into the network at a time of detection 
of the congestion condition, and a current receiver buffer size at that time...." No such limitation 
of 'the network congestion condition detected in response to an occupancy threshold of a 
transmit buffer of a sender' and the resulting claimed actions are found in the combination of 
Borella and Ohyama. For at least this reason it is respectfully submitted that the rejection under 
35 U.S.C. §103 is overcome and should be withdrawn. 
Claim 3: 

Dependent claim 3 recites "...The method of claim 1 , wherein the network is a private 
network, and wherein a total bandwidth of the private network is allocated among a plurality of 
connections between a plurality of nodes in the private network to provide a desired bandwidth 
for each connection, and wherein the step of controlling new traffic maintains the desired 
bandwidth on the connection...." No such structure is shown or suggested in the combination of 
Ohyama and Borella. For at least this reason it is requested thai the rejection of claim 3 be 
withdrawn. 
Claim 6: 

Applicants claim 6 recites *\..A method of controlling congestion in a communications 
network, the method comprising ... determining whether a congestion condition is present in 
response to an occupancy threshold of a transmit buffer in the communications network ... when 
a congestion condition is present, setting a congestion window size to a prescribed value , 
wherein the prescribed value is the lesser of a current amount of unacknowledged traffic emitted 
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by the sender into the network at a time of detection of the congestion condition, and a current 
receiver buffer size at that time ... and controlling traffic from a sender delivered onto the 
network so that the amount of unacknowledged traffic from the sender on the network does not 
exceed the congestion window size..." No such structure is shown or suggested in the 
combination of Ohyama and Borella. Accordingly, for at least the reason that the combination of 
Borella and Ohyama fail to describe all the limitations of the claims, the rejection is overcome 
and it is requested that it be withdrawn. 



Claim 8: 

Applicant's claim 8 has been amended to recite the steps of "...A method of controlling 
congestion on a connection in a network coupling a transmitting and receiving node, wherein the 
network is a private network and each connection in the network has an allocated bandwidth, the 
method including the step of ... forwarding packets on the connection at a bandwidth allocated to 
the connection ... monitoring the connection for indications of congestion on the connection, the 
indications including indications of dropped packets ... and controlling a rate of retransmission 
of the dropped packets to ensure that the allocated bandwidth of the connection is not 
exceeded..." 

No such structure is shown or suggested in Borella or Ohayma, alone or in combination. 
In particular, as pointed out in Applicants specification, the claimed architecture is associated 
with a system which uses a protocol other than TCP for transferring packets and controlling 
congestion in a network. As recited at page 6 of Applicants specification: 

"... the present invention uses Stream Control Transmission Protocol (SCTP) rather than 
TCP... SCTP provides a reliable transport service, ensuring that data is transported across the 
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network without error and in sequence..." As described at page 10 of Applicants specification, a 
modified SCTP may advantageously provide the following benefit: when the behavior of 
sources can be anticipated or controlled to regulate the amount of traffic on the network, it is 
possible to avoid congestion by making end-to-end connections look like fixed bandwidth pipes 
where the total bandwidth allocated to these connections stays within the limits of the bandwidth 
of the available network..." No such system is contemplated by Ohyama, Borella or the 
combination thereof. For at least this reason, claim 8 is patentably distinct over the combination 
of references, and the rejection should be withdrawn. New dependent claims 9-13 depend from 
and serve to add further patentable limitations to claim 8, and are allowable for at least the 
reasons put forth with regard to claim 8- 
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Conclusion: 

Applicants have made a diligent effort to place the claims in condition for allowance. 
However, should there remain unresolved issues that require adverse action, it is respectfully 
requested that the Examiner telephone the undersigned, Applicants' Attorney at 978-264-6664 
that such issues maybe resolved as expeditiously as possible. 

For these reasons, and in view of the above amendments, this application is now 
considered to be in condition for allowance and such action is earnestly solicited. 

Respectfully Submitted, 




Date 




Attorney/Agent for Applicant(s) 
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